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Web Security: PKI 



Public Key Infrastructure (PKI) underpins the 
security and trust infrastructure of the Internet, and 
while the protocol itself has manifest chinks in its 
armor from time to time, it has largely stood the 
test of time as an effective mechanism for 
establishing trust and ensuring confidentiality, 
integrity and authenticating previously unknown 
participants to secure Internet-based transactions. 



Web Security: a Multi-party Responsibility 



Effective PKI requires appropriate implementation, and 
ANY of the parties involved can contribute to whether 
effective trust is achieved or not : 

- the policies and practices of the Certification Authorities (CA) 
issuing certificates, 

- the practices and capabilities of the Browser managing certificates, 

- the practices of the site administrator or Site Operator configuring 
and utilizing certificates, 

- and the practices of the web User relying upon certificates. 
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SSL/TLS: The process 



CA 




Hello, let's set up a secure SSL session 
Hello, here is my certificate -^H 



Also checks that: 

• Certificate is valid 

• Signed by someone 



Here is a one time, encryption key for our session 
(encrypted using Server's public hey) 




Server decrypts session key using its private 
key and establishes a secure session 



01010010110 01010010110 



Site 
Operator 
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Web Security: a Multi-party Responsibility 



This session will examine each participants role in relation to the 
establishment of security and trust: 
Certification Authorities: 

- typically the first to have fingers pointed at them when something goes wrong 

- who you decide to trust can make a difference 
Browsers: 

- what tools are available to users to control their browsing experience, 

- what tools could/should browsers provide but don't, 

Site operators: 

- what they could/should be doing to ensure a safer and more efficient browsing 
experience for their users 

Users: 

- what to do to ensure a safe browsing experience and to leverage the tools and 
infrastructure that is available 
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Certification Author^ 






CA 
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What is a Certification Authority 



CA generates "roots" in secure 

environment - ceremony, video recorded, 

audited, keys on HSMs 

CA undergoes rigorous third party audit 

of operations and policy 

CA private keys are held under extreme 

protections and used to sign web site 

certificates and status information 

CA applies for corresponding root 
certificates to be included into trusted 
root stores 

CA policy and operations must be in 
compliance with Browser root store rules 
in order to be trusted by default, and may 
be distributed by software updates 



dig ice 



Secure Data Centre 




BROWSER 




smmwsim 




When issuing a SSL/TLS cert to a web site, the CA verifies 
certain information relating to ownership of the site with the 
respective domain and verifies control of keys b Qinri " oqH 

- This minimal validation is called Domain Validation or DV 

- While DV certificates verify the consent of a domain owner, 
make no attempt to verify who the domain owner really is. 

Stronger verification of site and domain ownership and 
controls for the organizations to which certs are issued 
allows issuance of higher assurance SSL certificates 

- This additional validation is called Organization Validation or OV 

- Additional checks include that they are registered and in r, ™ H ctanrlinri 
with their respective governments etc. i ) 
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What is a Certification Authority? 



The strongest verification of site and domain ownership 
with multiple verification of direct contacts etc., allows 
issuance of the highest standard of assurance for SSL 
certificates 

- This highest tier of verification is called Extended Validal 

- EV issued certs are recognized in browser GUI e.g. greer ^\V 



SSL Certificates DigiCert Digital SSL Certi... | + | 
^- A DigiCert, Inc. (US) https://vwtfw.digkert.CQm 




SSL/TLS: CA Role in Pl 



CA provides certs (DV or OV or EV) to customers 
chaining to trusted roots embedded in Operating 
Systems and Browsers 

CA Customers (Site Operators) install certs on their 
servers for secure web pages 

Users (clients of CA Customers) go to secure web pages 
HTTPS://, User Agent checks for CA's root inclusion in 
browser trusted root store 

If CA's root is in browser's trusted store: 

encrypted session, favorable padlock 



Ul (including EV green bar) 
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SSL/TLS: The process 



CA 





Hello, let's set up a secure SSL session 
Hello, here is my certificate -^H 



Also checks that: 

• Certificate is valid 

• Signed by someone 



Here is a one time, encryption key for our session 
(encrypted using Server's public hey) 



Server decrypts session key using its private 
key and establishes a secure session 



01010010110 01010010110 



Site 
Operator 



i 
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SSL/TLS: CA Role in Pl 



If CA root not in client trusted root store 

for browser - warning displayed 

CAs and browsers have the ability to 

revoke roots, sub-CAs, and certificates 

for any problems 

CAs publish revocation lists (CRLs) or 

provide updated certificate status 

information online (OCSP) 

If certificate revoked or expired - warning 

displayed 

CAs must complete annual audits and 

follow CA/B Forum rules to remain in 

browser trusted root stores 

Stronger rules and higher CA standards 

are set for green Extended Validations or 

"EV" display 



The site's security certificate is not trusted! 












3 SSL Certificates DigiCert Digital SSL Certi... | + | 
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EFORE THE SECURE SESSION REQ^H 
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1 he merchant creates a public and private The CA reviews the merchant's 
key and sends the public key to the CA. legal documents. 



1# 





The CA reviews the merchant's 
status through online resources 



The CA verifies that the merchant 
has the private key 





The CA checks the merchant's 
public key. 



If approved and payment is received, 

the CA "signs" the merchant's info 

arid public key. 




The CA checks the merchant's If approved and payment is received, 

public key. the CA "signs" the merchant's info 



These steps 
omitted for DV 
certificates 
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SSL/TLS: Brow< 


ser Role in Pr< 














• 
• 
• 
• 
• 


Browser publishes a set of requirements for inclusion of 
trusted CAs into its root store 

Browser evaluates CA applicants for inclusion against 
published criteria 

Browser update process allows for inclusion or removal 
of trusted roots 

Browser also allows Users to manually manage which 
roots they choose to trust and for which purposes 

Browser periodically reviews CA audit data to ensure 
that included roots are still in compliance with trust 
program 
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SSL/TLS: Browser Role in Process 



Browser users go to secure web pages HTTPS://, 

Browser performs the following checks on the site 
certificate being used: 

- matches name in location bar to those certified in the site 
certificate (subjectAlternativeName) 

- verifies that the site has control of the private key corresponding 
to the public key included in the site certificate 

- checks that the site certificate is within its published validity 
period, and that it is being used for appropriate purposes 

- checks for inclusion of CA's root and or intermediate sub-CAs 
(the chain) in the trusted root store 

- checks the current status of the site certificate (and its chain) 
with the CA using OCSP or CRL 
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SSL/TLS: Bro\ 



Role in P. 



If CA not in browser trusted 
root store, or any of the 
checks pre-defined above 
fails for any cert in the chain 

- warning displayed 

If CA's root is in browser's 
trusted store, and all other 
checks are passed: 

- encrypted session established, 
favorable padlock 

- Ul (including EV green bar) 

Browser messaging and 
indicators are critical 






<P 
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The site's security certificate is not trusted! 



ft Secure https: 
eBusiness* 



L 




What's behind the ffihttps://wvwi 

PADLOCK? * 




The browser or application responds accordingly: 



If the certificate passes all checks, the 
browser sets up a secure session, encrypt- 
ing all traffic between it and the merchant 



■[Jhttpsl 



It adds a padlock symbol and "https" to 
the URL address bar, and proceeds with 
the transaction. 
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Site Operators must enable SSL/TLS protocols on the 
applications running on their site 

- consideration for the protocol parameters used should be based 
on user capabilities and security expectations 



Keys must be generated and used to provide a CSR to 
the chosen CA 

- When creating a request, you generate a key pair (a private key 
and a public key) 

- Public keys are included in the CSR and embedded into the 
certificate by the CA, 

- Private keys MUST be secured on the site because that is how 
you prove you are the one authorized behind the public 
certificate that represents you 

- Use strong algorithms and secure processes to generate 
appropriate keys 
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SSL/TLS: Sites Role in Process 



Choose a CA that is trusted in the browsers used by the 
applications expected users 

- Not all CAs are the same 

- Review certifications and practices 

- Understand performance capabilities and services 

Choose the right certificate type for the information or 
data that is being protected 

- When to use DV vs OV vs EV 



Install certificate from CA in application and configure 
trust chains 



Ensure data being transferred between site and 
browsers is appropriately protected 

- Always On SSL should be configured so that not just initial 
authentication of Users is enabled, but protection of transactions 
from User login through User logout is in place 

- Configure back-end database or third party communications to 
also be secured so that would-be attackers cannot simply go 
around the TLS secured channels 



Maintain DNS records with appropriate and up-to-date 
information 
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SSL/TLS: Sites Role in Process 



Monitor site 

- Watch for inappropriate traffic 

- Revoke certificate if private key becomes compromised 

- Update certificate BEFORE it expires 

- Keep application software patched and up-to-date 

Only use private key and certificate in accordance with 
intended usages 

- Avoid over-exposure of key material 



Employ network and physical protections on private keys 

- Use firewalls and intrusion and/or extrusion detection services to 
ensure private data and cryptographic keys are being protected 

- Use HSM to store private keys when physical protections are not 
sufficient 





User 
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SSL/TLS: Users Role in Process 



How can a web User be sure they are or remain 
protected in the SSL/TLS process? 

- Keep browser up-to-date 

- Watch for appropriate queues in the browser 

• Name in location bar is where you expected to go/be 

• Protocol being used is HTTPS 

• Lock to indicate a secure connection is established 

• DO NOT ignore pop-up warnings in the browser chrome, review carefully 
and respond appropriately 

• Validate that content is appropriate and expected (Logos - site or 
association, site seals, expected link contents and values) 

• Review information in security certificate upon initial visit and periodically 
thereafter 

- Utilize browser tools or plugins to restrict active content for new 
or relatively new sites visited 

- Only enter appropriate sensitive data once you are confident you 
have the right site 
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SSL/TLS: Users Rol. 



How can a web User be sure they are or remain 
protected in the SSL/TLS process? 

- Don't enable global security exceptions inappropriately 

• If choosing to trust a previously unknown or untrusted CA or server 
certificate, consider doing so just for that session 

• Consider why the site is not using an already trusted TLS credential 

- Don't manually install CA roots or intermediate CAs from 
untrusted sites, or if they were not obtained via a secure and 
reliable mechanism 

- Don't install plugins or add-ons from untrusted sites 

- Consider using different browser instances for casual browsing 
vs secure transactions 

- Run AV and other scanning services to interrogate active 
content before launching it on your system 



digicert 




Dartmouth Usability Study 



In 2009 Dartmouth College conducted a browser security 
usability study under an NSF grant 

- > 82% of respondents surveyed claimed to look for security indicators in the 
web-browser interface 

- Yet 27% said they did not know WHERE to look for indicators 

- The LOCK was the predominant indicator recognized followed by HTTPS in 
location bar 

- This self-reported behavior was in contrast with the actual browsing habits 
observed in the second part of the usability study 

- > 70% of respondents were phished by a reasonable facsimile of an original site 

- 20% of respondents did NOT log into a legitimate site because it was unfamiliar 
to them and "looked suspicious" 

- -50% of respondents suspected a server compromise of a legitimate site with a 
mis-configured certificate, the other 50% did not understand the security 
messages in the browser chrome 

- A plugin was developed to help interpret browser chrome security messages 
with clearer and more concise feedback, prominently located in the viewing 
window of the content, and the capability to "pin" sites (block or enable future 
access based on a user decision) 
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Dartmouth Usability Study 



_ 



Conclusions of 2009 Dartmouth College browser security 
usability study: 

- Developed plugin dramatically reduced phishing success: 25% were still fooled, 
but this is a massive improvement from the 70% who were previously fooled 
when relying upon existing browser indicators 

- Developed plugin dramatically improved the understanding of the User in what 
the security messaging of the browser was trying to indicate: -84% of 
respondents had a high confidence in understanding messaging which was an 
improvement from -50% who claimed to understand the native browser 
messaging fcBiTl/TlflrTT'lNl.iiiJ-l .i J ,lffl 



Edit View History Bookmarks Tools Help 
4l •$ •*■ B ^| J[cj^^ SB http5:/A~nm.cs.dartmouth.ediV 



J 13^ Google 



^1 Most visited ^ io Getting 5tarted | ji 

■f 




- Conclusion was that security indicators in applications should (a) provide 

consistent and active messages, (b) provide simple, clear and short information, 
(c) minimize the impact of the browsing experience to the user and (d) appear 
where the user's attention is focused 
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Hello, let's set up a secure SSL session 
Hello, here is my certificate ^JB 



■ * 



Also checks that: 

• Certificate is valid 
Signed by someone 



3 Here is a one time, encryption key for our session 
(encrypted using Server's public hey) 



Server decrypts session key using its private 
key and establishes a secure session 



Site 
Operator 



01010010110 
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Certification Authority Security Issues 














V^riSigrr (2001) 

• Problem: Erroneous authentication for code signing 

certificate in name of "Microsoft" 

• Harm: None detected 

• Response: Browsers "untrusted" the bad cert, 

authentication team member terminated 
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Certification Authority Security Issues 



comooo (2011) 

Creating Trust Online* * ' 



Problem: CA's system hacked through external 

RA/Reseller portal; 9 fake certs issued for 
various top domains 

Harm: Unknown. Hacking claims by "Iranian hacker" 

never verified 

Response: Certs quickly revoked by CA and "untrusted" 
by browsers 



Certification Authority Security Issues 



J^DigiNotar (2011) 



Internet Trust Services 



Problem: 



Harm: 



Response: 



Hacking/complete compromise of CA system 
over many months; cert issuance logs 
erased (no record); 531 or more fake certs 
issued 

Potentially great (many OCSP checks from 
Iran). Hacking claims by "Iranian hacker" 
never verified 

Some certs revoked by CA (no complete list). 
DigiNotar roots "untrusted" by browsers; 
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Certification Authority Security Issues 



Entrust Independent Malaysian Sub-CA (201 1 ) 



Problem: 



Harm: 



Response: 



Independent Sub-CA issued 22 512-bit certs 
off chained root - too weak, no EKU limiting 
extension to TLS server certs, violated 
CA/Browser Forum rules 

Cert stolen from Malaysian government, 
compromised, used to sign malware 




Browsers issued patch to "untrust" the Sub- 
CA, all certs; new rules to audit sub-CAs 



digice 



Certification Authority Security Issues 



TirtK"RUSr v (2012) 



Problem: 



Harm: 



Response: 



Customer cert issued with wrong extensions - 
customer had powers of a sub-CA, could 
issue certs in other domain names 

None detected. Unintentionally used by 
customer at firewall in MITM configuration; 
accidentally issued "google.com" cert - 
never used. 

Cert revoked and "untrusted" by browsers, all 
CAs scanned past certs 
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Certification Authority Security Issues 



ETrustwave (2012) 



Problem: 



Harm: 
Response: 



CA issued Sub-CA cert to enterprise for MITM 
security screening of enterprise email and 
web communications; could be used to 
create certs for top domains 

None detected. However, controversial 
practice, now deprecated by several 
browsers 

Trustwave revoked 'MITM Sub-CA and 
discontinued issuing them to enterprise 




3HSE3H1 



Certs issued worldwide: 2,000,000 per year 

Bad certs issued: maybe 1 ,000 over 1 1 years (-91 
bad certs per year) - mostly single incident 
(DigiNotar) 

Accuracy ratio for certs issued each year: 99.995% 
(Error rate 0.005%) - US Passport Office and state 
Departments of Motor Vehicles are NOT this accurate 

Significant harm from bad certs? Only likely in 
DigiNotar case (actual harm unknown) 

CAs are continuously improving security, processes 

The state of SSL is stronger today, because of these 
responses 
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Putting CA Attacks Into Perspectiv 



Relatively few CA security issues over 15 years 

- Most breaches resulted in no known harm 

- Quickly remediated 

- Industry practices constantly improved by CAs, 
browsers - without government regulation 

- Browser root program requirements raise the bar 

- CA/Browser Forum (2005 to date) - raised the bar: 

• EV Guidelines (2007), Baseline Requirements (2011), 
Network and Security Controls (2013) 

• WebTrust, ETSI audit requirements (2000 - date) 

• New: CA Security Council www.casecurity.org 
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asic Reauirements 














• 12 Commandments for BR: 

- Minimum standards in validation of certificate information 

- RA audit requirements (applicable where the RA can cause cert issuance 

- Sunset date for 5 year certificates 

- CAs are required to provide a notice to applicants that the use of certificates 
containing an internal (NetBIOS) name has been deprecated. 

• CAs are not allowed to issue certificates with internal names that have an expiration 
date after Nov 1,2015 

• On October 1 2016, all CAs are required to revoke certificates with internal names. 

- Elimination of issuance directly from a root cert 

- Mandatory OCSP 

- Mandatory background checks on employees and sub contractors (including 
RAs) 

- Document and data retention requirements (7 years) 

- Minimum audit standards and self-audit requirements 

- Security requirements (these are being expanded in the Forum's minimum 
security guidelines, currently under discussion) 

- Private Key Protection requirements 

- Key Ceremony requirements 
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Why Attack CAs? 




• Attackers are trying to get control of a credential issued 
by a trusted CA so that unsuspecting users can be 
fooled into trusting a transaction that conies from a 
malicious source, without getting any warnings 

• Not only are there Root CAs that must be trusted, but 
any sub-CA in the trust chain must also be trusted 

• For an application to "trust" a credential, it must be 
issued by a trusted authority for the intended purpose by 
the credential 

- Warnings are given to the user when this is not the case 
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Why Attack CAs? 




• Instead of attacking a web site directly to try to gain 
access to its private key, and thus impersonate you, and 
be trusted just like they were you, an attack is more 
efficient if it can target the issuing CA directly 

- This allows the attacker to generate as many keys as it wants 
and submit to a trusted CA : as long as they can convince the 
CA that they are really you 

- Instead of just one domain compromise resulting from the attack, 
they can potentially get many for the price of one 

• CAs are definitely in the cross-hairs of attackers 

- The potential impact of a successful compromise is far more 
lucrative than targeting specific sites one-by-one 
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Why Attack CAs? 




• Not all CAs are created equal 

- Out of the many trusted Root CAs for an application, 
some perform better than others in protecting their 
customers with better processes and more secure 
systems 

- As evidenced earlier, attackers are targeting lots of 
different CAs looking for any weaknesses they can 
exploit 

- One issue identified with the current system, is that all 
CAs are typically treated equally trusted, when in fact 
they should/are not 

- An important decision for service owners is to choose 
a CA that is more secure, more trusted, less likely to 
be compromised 
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uhoosina Your UA 










• There are a number of considerations to take into account when 
choosing a CA for issuing your certificates 

- Is your CA trusted in the platforms/applications you wish to support? 

- Does you CA have high standards for identity verification and issuance 
processes 

• Does you CA support EV or OV certificates 

• Does your CA support CAB Forum standards (Baseline Requirements, 
Network and Security Requirements) 

• Is your CA WebTrust audited? 

• Review the identity practices utilized in identifying and issuing certificates 

- Does your CA have a record of strong security practices? 

- What are the SLAs and performance associated with validation 
services? 

- Does your CA proactively provide you with information that might be 
pertinent to the protection of your certificates? 

- How good is the Customer Service? 

- Can you rely upon your CA to respond quickly and efficiently if you have 
any issues, concerns or problems with your certificates? 
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When Browsers Get It Wrong 




rowsers behavim 



m 



The Dartmouth study referenced earlier demonstrates 
that browsers in general do not have the right security 
messaging/feedback implemented 

- Users do not understand it 

- It is not consistent across platforms 

- Success messaging is not easily recognizable in the view of the 
User and failure messaging is too intrusive 

Browsers are not necessarily checking revocation of 
certificates 

- More of a problem for mobile environments 

- Intermediate CAs are not being validated on some platforms 

- Only EV certs might have entire chain validated 
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Browsers Behaving Badl 1 



Browsers do not differentiate between CAs or assurance 
levels of certificates 

- A flat one tiered trust model is used i.e. all CAs are trusted 
equally 

- EV certificates are differentiated but OV and DV are not 

- CAs are typically trusted for global scope 

Browsers make managing certificates a challenge for 
Users 

- Trust settings for certificates are buried multiple levels deep in 
the configuration dialogs 

- Little capability to differentiate trust for different trust zones i.e. 
Internet vs Enterprise trust or just for a specific site 



What Could Browsers Do' 



Suggestions for Browsers to improve the security of 
SSL/TLS: 

- Implement Clear, Concise, Consistent, and Conspicuous 
security-related messaging 

- Differentiate between different levels of certificate assurance 
(more than just EV) 

- Allow simple access to certificate management, and allow 
capability for more flexible and scoped configurations 

- ALWAYS check revocation status for the entire certificate chain 

- Implement CA and certificate pinning capabilities 

- Support certificate issuance transparency 
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CA Pinning 



CA Pinning / HSTS Pinning / CAA record in 
DNSSEC / Sovereign Keys 

Overview : 

- Sites may want to also restrict the CAs who can issue 
certificates for their domain to a few that they trust. 

- This can be accomplished via a list of certificate 
fingerprints/names/keys that are exclusively allowed 
to act as trust anchors for a given domain 

- This list can be included in specific site HTML or 
HSTS headers or in a DNS record served up over 
DNSSEC 



What Site Operators Can Also Di 






Site 
Operator 
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Operators 



To enable more secure and efficient SSL/TLS 
transactions, Site Operators should also do the following: 

- Ensure web services remain patched and up-to-date 

- Turn on OCSP Stapling for web services 

- Choose a CA with compatible services and security posture 

• This should NOT be a financial ONLY decision but rather a cost/benefit 
value proposition 

• Review audit reports and industry certifications held 

• Is your CA of choice adequately prepared and actively participating in the 
development of future technology and practices to secure the community? 

- Consider appropriate assurance levels in certificates being 
deployed and how they are deployed 

• Use higher assurance certificates where warranted 

• Reduce the exposure of private key usage 
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CA 
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Hello, let's set up a secure SSL session 
Hello, here is my certificate ^JB 






Also checks that: 

• Certificate is valid 

• Signed by someone 



Here is a one time, encryption key for our session 
(enoypted using Server's public hey) 



Server decrypts session key using its private 
key and establishes a secure session 



Site 
Operator 



01010010110 
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Web Security: a Multi-party Responsibilit 1 



Effective PKI requires appropriate implementation, and 
ANY of the parties involved can contribute to whether 
effective trust is achieved or not : 

- the policies and practices of the Certification Authorities (CA) 
issuing certificates, 

- the practices and capabilities of the Browser managing certificates, 

- the practices of the site administrator or Site Operator configuring 
and utilizing certificates, 

- and the practices of the web User relying upon certificates. 





SSL/TLS: Friend or Foe? 
















• So is SSL/TLS a friend or foe? 

- The answer to this is that it depends... there are multiple parties to any given 
transaction, and actions taken or omissions of actions that should/could be taken by 
the participants will determine the outcome. 

- CAs who have often bore the brunt of criticisms when things fail, have done much to 
improve SSL/TLS security in a time of increased attacks and scrutiny. Choosing 
which CA to use is a critical security consideration. 

- CAs, Browsers, and Site Operators must work together to provide Users with a more 
secure browsing experience 

- More education on security aspects, and consistent browser messaging will aid Users 
in protecting themselves and securing their transactions appropriately 
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Website: http://www.DiqiCert.com/ 



Scott Rea: +1 (801) 701-9636, Scott(a>DiaiCert.com 



